home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-iplpdn-para-negotiation-02.txt
< prev
next >
Wrap
Text File
|
1993-09-02
|
14KB
|
499 lines
Draft Parameter Negotiation August 1993
INTERNET DRAFT
Expires: February 25, 1994
Parameter Negotiation
for the
Multiprotocol Interconnect
Keith Sklower
Computer Science Department
University of California, Berkeley
Clifford Frost
Information Systems & Technology
University of California, Berkeley
1. Status of This Memo This document is an Internet
Draft. Internet Drafts are working documents of the Inter-
net Engineering Task Force (IETF), its Areas, and its Work-
ing Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not appro-
priate to use Internet Drafts as reference material or to
cite them other than as a ``working draft'' or ``work in
progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the current status of any Internet
Draft.
2. Abstract
This document describes mechanisms for negotiating opera-
tional parameters wherever the use of an ISO TR9577 NLPID is
available.[6] For example, it is suitable for use in con-
junction with RFC 1490 (Multiprotocol Over Frame Relay) and
RFC 1356 (Multiprotocol Interconnect on X.25 and ISDN in the
Packet Mode) [1,2], and potentially others. The mechanisms
described here are intended as optional extensions, intended
to facilitate interoperation in public networks were precon-
figuration may not have been done symmetrically by all par-
ties who wish to exchange information.
Sklower & Frost [Page 1]
Draft Parameter Negotiation August 1993
3. Acknowledgements
The authors wish to thank Brian Lloyd of Lloyd & Associates
and Bill Simpson of Daydreamer, Inc. for extensive discus-
sion of the PPP protocol, and this draft draws heavily on
some ideas advanced by Bill in related work. Brad Steinke
of Microcom, and Joel Halpern of Network Systems for useful
suggestions, and especially Chris Ranch of Novell for
details about the protocol itself.
4. Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL or MANDATORY -- the item is an absolute
requirement of the specification.
o SHOULD or RECOMMENDED -- the item should generally be
followed for all but exceptional circumstances.
o MAY or OPTIONAL -- the item is truly optional and may
be followed or ignored according to the needs of the
implementor.
5. Introduction
When parties wish to exchange information over a public data
network, it may be useful to perform sanity checks, such as
verifying that buffer sizes are sufficient to receive data
being transmitted, or that there is agreement as to which
protocols will be routed or bridged. As another example,
there may be circumstance in which the identity of a calling
party may not be readily available; thus some form of
authentication may be desired.
The Point-to-Point Protocol (RFC 1331 and 1332) provides a
means of achieving these goals [3,4]. It is very general
and can be adapted to any situation where there is a virtual
point-to-point connection between parties wishing to
exchange information. Both RFC's 1490 and 1331 specify
details of framing and encapsulation in incompatible ways;
however, one can accommodate PPP's encapsulation of control
packets by prepending a NLPID without otherwise changing the
description of the packets. Negotiations are currently
under way with ANSI for the assignment of a NLPID; it is
believed that the numeric value CF (hex) will be assigned to
this purpose.
Members of the IPLPDN group expressed the desire that param-
eter negotiation as a whole be made optional, and also
wanted to be able to renegotiate parameters at any time dur-
ing the course of an association.
Sklower & Frost [Page 2]
Draft Parameter Negotiation August 1993
6. Frame Format
6.1. Basic Format
In this document, we propose prepending an NPLID to that
portion of PPP control packets that follow link media head-
ers, such as the two byte PPP address and control field.
The NLPID value is 0xCF. A system SHOULD recognize incoming
PPP data packets. We RECOMMEND that only control or negoti-
ation type PPP packets be transmitted in this fashion, since
RFCs 1490 and 1356 already specify a means of encapsulating
data packets.
Since we are proposing using this in conjunction with both
RFC1490 and RFC1356, we give an example in each packet for-
mat:
Sklower & Frost [Page 3]
Draft Parameter Negotiation August 1993
Sample Frame Relay PPP LCP packet
+-----------------------------+
| flag (7E hexadecimal) |
+-----------------------------+
| Q.922 Address |
+-- --+
| |
+-----------------------------+
| Control (UI = 0x03) |
+-----------------------------+
| Optional Pad(s) (0x00) |
+-----------------------------+
| NLPID 0xCF |
+-----------------------------+
| PPP Protocol (e.g. 0x0c) |
+-- . --+
| PPP Protocol (0x21 for LCP)|
| (two octets) |
+-----------------------------+
| Data |
| (e.g LCP Code ) |
+-----------------------------+
| (e.g LCP Identifier) |
+-----------------------------+
| (e.g. LCP Option Length)|
+-- . --+
| (two octets) |
+-----------------------------+
| (e.g. LCP Option) |
| . |
| . |
| . |
| . |
+-----------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+-----------------------------+
| flag (7E hexadecimal) |
+-----------------------------+
Sklower & Frost [Page 4]
Draft Parameter Negotiation August 1993
Sample X.25 PPP LCP packet
+-----------------------------+
| flag (7E hexadecimal) |
+-----------------------------+
| Address A or B 0x1 or 0x3 |
+-- --+
| LAPB Control |
+-----------------------------+
| D,Q bits | SVC# high order |
+-----------------------------+
| SVC low order |
+-----------------------------+
| p(r) | m_bit | p(s) | 0 |
+-----------------------------+
| NLPID 0xCF |
+-----------------------------+
| PPP Protocol (e.g. 0x0c) |
+-- . --+
| PPP Protocol (0x21 for LCP)|
| (two octets) |
+-----------------------------+
| Data |
| (e.g LCP Code ) |
+-----------------------------+
| (e.g LCP Identifier) |
+-----------------------------+
| (e.g. LCP Option Length)|
+-- . --+
| (two octets) |
+-----------------------------+
| (e.g. LCP Option) |
| . |
| . |
| . |
| . |
+-----------------------------+
| Frame Check Sequence |
+-- . --+
| (two octets) |
+-----------------------------+
| flag (7E hexadecimal) |
+-----------------------------+
Since one of the packet formats specified in RFC1356 permits
logically prepending the call user data supplied when the
virtual circuit was established to each packet transmitted
over that virtual circuit, one could transmit PPP packet
unchanged if the single byte NLPID is supplied as the call
user data.
RFC1356 allows the use of single SVC connections between
systems (termed the null encapsulation) indicated by the use
of a single byte CUD with value 0. In the elements of
Sklower & Frost [Page 5]
Draft Parameter Negotiation August 1993
proceedure described below, if a system initiates traffic
over such an SVC and subsequently initiates parameter nego-
tiation with a system that may not have implemented this
extension, all traffic becomes blocked until the initiating
system has exhausted its PPP timers, whereas the system will
reject a call request with a single byte CUD with the PPP
value immediately. Also, PPP encodings for some protocols
are more compact. Thus we RECOMMEND that when there are
sufficient SVCS available, traffic requiring parameter nego-
tiation be sent over a separate SVC.
6.2. Supported Types
The PPP protocol is a rich language and allows many options
to be negotiated. An implementation MAY request any option
specified by PPP, but MAY decline to support any option.
Because PPP and Frame Relay encapsulations evolved indepen-
dently, there are duplicate ways to obtain configuration
information such as the IP address of the other end of the
PVC - by inverse arp, or determine the transmit and receive
buffer sizes - by XID negotiation. Where there are such
choices, it is RECOMMENDED that an implementation adhere to
practice specified in the Frame Relay and X.25 RFCs. Manual
configuration also implicitly provides information that may
otherwise have been explicitly negotiated.
7. Elements of Proceedure
As noted above, people have expressed the desire not to be
required to conduct any negotiations before transmitting
data packets in a public data network environment. Thus, an
implementation MAY silently ignore any SNAP encapsulated PPP
packet. If an implementation responds to LCP packets, it
MUST traverse the LCP state diagram according to RFC1331.
If an implementation responds to NCP packets for any partic-
ular protocol, it MUST otherwise obey the rules of the RFC
for that corresponding NCP.
An implementation MUST NOT accept the address and control
field option. An implementation MAY accept the protocol
identifier compression option; however in the case of frame
relay use, we interpret this to mean that the NLPID always
remains present, but the higher order zero valued byte of
the protocol identifier field may be removed.
One reason for making negotiations optional is cost; there
are environments which charge by the packet and there are
applications such as mail hubs which generally exchange only
a few data packets with a given remote host and then will
not exchange any other packets for relatively long periods
of time.
Sklower & Frost [Page 6]
Draft Parameter Negotiation August 1993
Another reason is simplicity of implementation. For use of
small computers at home, people may wish to be able to only
support the required packet framing. Or, for routers at
campus or business hubs, this could reduce memory require-
ments from having to maintain state information for hundreds
of virtual point-to-point connections.
Another reason is reduction of latency.
8. References
[1] Bradley, T., Brown, C., and Malis, A., "Multiprotocol
Interconnect over Frame Relay", Network Working Group,
RFC-1490, January 1992.
[2] Malis, A., Robinson, D., Ullman R., "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", Net-
work Working Group, RFC-1356, August 1992.
[3] Simpson, W., "The Point-to-Point Protocol (PPP) for the
Transmission of Multi-protocol Datagrams over Point-to-
Point Links", Network Working Group, RFC-1331, May
1992.
[4] McGregor, G., "The PPP Internet Protocol Control Proto-
col (IPCP)" Network Working Group, RFC-1332, May 1992.
[5] Postel, J. and Reynolds, J., "A Standard for the Trans-
mission of IP Datagrams over IEEE 802 Networks", ISI,
RFC-1042, February 1988.
[6] International Organization for Standardization, "Infor-
mation technology - Telecommunications and Informations
exchange between systems - Protocol identification in
the network layer", Technical Report 9577, October
1990.
[7] Simpson, W. A., "PPP in Frame Relay" and "PPP in X.25",
Lansing Michigan, 1993, unpublished.
9. Authors' Addresses
Keith Sklower
Computer Science Department
570 Evans Hall
University of California
Berkeley, CA 94720
Phone: (510) 642-9587
E-mail: sklower@cs.Berkeley.EDU
Sklower & Frost [Page 7]
Draft Parameter Negotiation August 1993
Clifford Frost
Information Systems & Technology
275 Evans Hall
University of California
Berkeley, CA 94720
Phone: (510) 642-5360
E-mail: cliff@cmsa.Berkeley.EDU
10. Expiration Date of this Draft
February 25, 1994
Sklower & Frost [Page 8]